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(57) Video and telephony messaging are integrated 
by a telephony nnultimedia messaging system (101) 
connected to a plurality of video workstations (103-104) 
by a LAN or WAN (100). The workstations are connect- 
ed to ISDN telephone lines (153-154) The workstations 
answer video calls on the video lines and/or on the LAN 
or WAN that go unanswered by users, record video mes- 
sages from the video calls, and send the video messag- 
es via the LAN or WAN to the messaging system for stor- 
age. They also retrieve stored video messages via the 
LAN or WAN from the messaging system and play them 
to users. The messaging system stores both video and 
non -video messages and has a telephony user interface 
(114-115 and 118) for storing and retrieving non-video 
messages and for accessing non-video portions of all 
messages. The video terminals perform functions, such 
as answering of video calls and recording of video mes- 
sages, on behalf of the telephony messaging system 
which cannot itself perform those functions, while the 
messaging system performs functions, such as provid- 
ing a rich set of messaging features and providing te- 
lephony access from a variety of different telephony ter- 
minals to at least portions of the video messages, on 
behalf of the video terminals which cannot themselves 
perform those functions. 
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Description 
Technical Field 

This invention relates to telecommunications mes- 
saging systems. 



Background of the Invention 

Single-media and multi-media messaging, wherein 
users create and send or leave voice, binary data. fax. 
etc. messages for recipients to or in the recipients' mail- 
boxes in the telephone network, are well known in the 
art. The addition of video as a messaging medium to the 
existing messaging media creates certain difficulties, 
however. For purposes of this discussion, video com- 
munications include moving pictures, moving pictures 
with synchronized audio, shared whiteboard, shared ap- 
plications, or any other communications that include 
moving images. The difficulties do not arise within the 
messaging systems themselves -multi-media messag- 
ing systems are often internally capable of handling vid- 
eo objects (that is, portions or components of the mes- 
sage that are represented in the video medium) as a 
direct extension of the manner In which they handle any 
one or more of the voice objects, binary data objects, 
fax objects, etc. Rather, the difficulties arise in the inter- 
faces to the messaging systems Firstly while video 
messages and multi-media messages that include vid- 
eo components may be transmitted through telephone 
networks as video calls, many telephone switching sys- 
tems do not have the capability of redirecting video calls 
to coverage. They therefore lack the ability to redirect 
video calls from their original intended destinations to 
messaging systems. This prevents the messaging sys- 
tems from serving one of their principal functions, which 
is to provide coverage for calls that go unanswered at 
their destinations. And secondly even if the switching 
systems are able to redirect video calls, most existing 
messaging systems lack the special port circuits that are 
needed to receive video calls and to play out recorded 
video messages through the telephone system. Hence, 
adapting of existing messaging systems to make them 
capable of serving video messages generally requires 
extensive and expensive redesign of their telephony in- 
terfaces. 

Local area networks (LANs) and wide area net- 
works (WANs) often provide the capability of transport- 
ing files of video information between workstations, and 
between workstations and network servers, that are 
connected to the networks, in substantially the same 
manner as they provide for the exchange of electronic 
mail (e-mail) messages. While there are substantially no 
difficulties that arise in these systems as a consequence 
of the messages including video objects, these systems 
have inherent limitations that do not make them suitable 
substitutes for telephony-based messaging systems. 
First, most of the LAN-based or WAN-based messaging 



systems also lack message redirection capability Sec- 
ond, they provide access to messages exclusively 
through video terminals, as opposed to telephony- 
based integrated multi-media messaging systems that 
s normally provide access to messages (or at least to 
message headers and a subset of the media objects of 
the message) through a variety of terminals, such as 
PCs, fax machines, telephones, data terminals, etc. And 
third, they are typically feature-poor, relative to the te- 
10 lephony-based messaging systems, in terms of the 
number and types of features that they offer to users for 
creating, retrieving, sending, and receiving of messag- 
es. Therefore, extending the capabilities of the LAN-and 
WAN-based messaging systems to match the capablli- 
'5 ties of telephony-based messaging system would be an 
extensive and an expensive development effort. 

Summary of the Invention 

^0 This invention Is directed to solving these and other 
problems and disadvantages of the prior art. According 
to an implementation of the invention, a video terminal 
is employed to perform functions, such as answering of 
video calls and recording of video messages, on behalf 
25 of a telephony messaging system which cannot itself 
perform those functions, while the telephone messaging 
system is employed to perform functions, such as pro- 
viding a rich set of messaging features and providing 
telephony access from a variety of different types of te- 
30 lephony terminals to at least portions of the video mes- 
sages, on behalf of the video terminals which cannot 
themselves perform those functions. This implementa- 
tion of the invention interfaces video terminals by means 
of a LAN or a WAN to a telephony multi-media messag- 
3S ing system to provide the telephony messaging system 
with the ability to receive and transmit video messages, 
and conversely the telephony multi-media messaging 
system provides the features and capabilities of conven- 
tional telephony-based messaging systems to video 
40 messages conveyed via the LAN or WAN. Consequent- 
ly, the telephony messaging system is made capable of 
serving video messages without extensive and expen- 
sive redesign of its telephony interface, and the mes- 
saging capabilities and features of telephony-based 
^5 messaging systems are extended to LAN-and WAN- 
based messaging without extensive and expensive de- 
velopment effort. Video messaging and telephony multi- 
media messaging are thus integrated with a minimum 
of effort and cost. The result, from the users' viewpoint. 
so is a universal mailbox; one location for accessing all 
rpessages regardless of what network delivered the 
messages, what media the messages are represented 
in, and what instruments or mechanisms are used to ac- 
cess the messages. This is a significant improvement 
55 over conventional messaging arrangements that typi- 
cally use separate delivery, storage, and access mech- 
anisms for at least video messages and messages rep- 
resented in other media types. 
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Generally according to the invention, a video mes- 
saging system is configured as follows. A multi-media 
message server is connected to both a LAN or a WAN 
(or some other video communications network) and at 
least one telephone line. The multi-media message 
server (such as a telephony multi-media messaging 
system, lor example) stores messages that have a plu- 
rality of message portions, and at least some of those 
message portions may be represented in any one of a 
plurality of different media, including a video medium. 
(An illustrative structure of such a message is shown in 
FIG. 2.) In other words, the multi-media message server 
can handle video objects. The multi-media message 
server has a first interface connected to the at least one 
telephone line for providing access over the at least one 
telephone line to at least some portions of the messages 
stored In the multi-media message server This is illus- 
tratively the conventional telephony messaging inter- 
face. The multi-media message server has a second in- 
terface connected to the video communications local ar- 
ea or wide area network for receiving video messages 
(i.e.. messages having portions represented in the video 
medium) via the video communications network and 
storing them in the multi-media message server, and al- 
so for retrieving the stored video messages and trans- 
mitting them via the video communications network. 
Furthermore, one or more video communications termi- 
nals are connected to the video communications net- 
work. The video communications terminals are, for ex- 
ample, video workstations. At least a first one of the vid- 
eo communications terminals handles video communi- 
cations incoming to the first terminal and which an in- 
tended recipient of the video communications has not 
answered (illustratively, either at the first terminal itself, 
or at another video terminal from which the video com- 
munication has been forwarded). Illustratively, an unan- 
swered incoming video communication may be incom- 
ing to the first terminal either via the video communica- 
tions network (for example, from one of the other video 
communications terminals), or via a video communica- 
tions line, such as an ISDN telephone line, that Is con- 
nected to the first terminal (for example, from some re- 
mote video caller). The first terminal includes means for 
answering the incoming video communication and re- 
cording a video message component from the video 
communication. The first terminal further includes 
means responsive to the recording, for transmitting the 
recorded video message via the video communications 
network to the multi-media message server, and caus- 
ing the second interface of the multi-media message 
server to receive and store the transmitted video mes- 
sage in the multi-media message sen/er (This is illus- 
tratively the call-answer scenario shown in FIG. 3.) At 
least a second one of the video communications termi- 
nals includes means for causing the second interface of 
the multi-media message sen/er to retrieve and transmit 
the stored video message, and for receiving the video 
message transmitted from the multi-media message 



server via the video communications network for pres- 
entation of the received video message to a user of the 
second terminal. (This is illustratively the message-re- 
trieval scenario shown in FIG. 4.) The first and second 

5 terminals may be different terminals, or they may be the 
same terminal. Preferably, one or more of the video 
communications terminals include means for a user of 
the terminal to create a video message on the terminal, 
sending the created message via the video communi- 

w cations network to the multi-media message server and 
causing the second interface of the multi-media mes- 
sage server to receive and store the sent message in 
one or more mailboxes in the multi-media message 
server (This is illustratively the mail-message scenario 

^5 shown in FIG. 5.) 

A message server and a video communications ter- 
minal for use in such a video messaging system are also 
characterized. 

A video messaging system configured in the man- 

20 ner characterized above may advantageously be con- 
structed from substantially conventional elements or 
may be retrofitted into conventional messaging infra- 
structure without extensive redesign or modification of 
the elements or infrastructure. This allows video mes- 

25 saging having telephony-like messaging features and 
capabilities to be implemented with minimal effort and 
at low cost. 

These and other advantages and features of the in- 
vention will become more apparent from the following 
30 description of an illustrative embodiment of the invention 
taken together with the drawing. 

Brief Description of the Drawing 
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FIG. 1 is a block diagram of a telecommunications 
system which includes a first illustrative embodi- 
ment of the invention: 

FIG. 2 is a block diagram of a multi-media message 
of the system of FIG. 1; 

FIG. 3 is a block diagram of a call-answer scenario 
of the system of FIG. 1: 

FIG. 4 is a block diagram of a message-retrieval 
scenario of the system of FIG. 1 ; 
FIG. 5 is a block diagram of a mail-message sce- 
nario of the system of FIG. 1 ; 
FIG. 6 is a flow diagram of operations of a worksta- 
tion of the system of FIG. 1 involved in the call-an- 
swer scenario of FIG. 3; 

FIG. 7 is a flow diagram of the operations involved 
in Tut large" and "Get large" commands in the sys- 
tem of FIG. 1; 

FIG. 8 is a flow diagram of operations of a worksta- 
tion of the system of FIG. 1 involved in the message- 
retrieval scenario of FIG. 4; 
FIG. 9 is a flow diagram of operations of a worksta- 
tion of the system of FIG. 1 involved in the mail-mes- 
sage scenario of FIG. 5; 

FIG. 10 is a block diagram of a telecommunications 
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system which includes a second illustrative embod- 
innent of the invention; and 

FIGS. 11-13 illustrate the messaging graphical user 
interface of a workstation of the system of FIG. 1 

Detailed Description 

FIG. 1 shows a block diagram of an illustrative tel- 
ecommunications system constructed according to the 
principles of the invention. In keeping with the objective 
of the invention to avoid extensive redesign or modifi- 
cation of existing infrastructure, all of the system hard- 
ware is conventional. The invention lies in this illustrative 
embodiment in the interconnection of the hardware and 
in video-handling enhancements to their conventional 
software. 

The system of FIG. 1 includes one or more video 
communications workstations 103-105. These are, illus- 
tratively, the AT&T Vistium® station, the Intel Proshare 
station, or a conventional UNIX® operating system 
workstation equipped with the Insoft Communique! soft- 
ware and video processing bpards. Each station 
103-104 includes a video display screen 130, a video 
camera 1 32, loudspeakers 1 31 , and a microphone 1 33. 
These are connected to media processing circuits 138. 
which are illustratively implemented as digital signal 
processors (DSPs), An integrated services digital net- 
work (ISDN) port 136 couples each video workstation 
103-105 to a respective one of telephone ISDN lines 
153-155. ISDN lines 153-155 connect the video work- 
stations 103-104 to a network 170 -such as the public 
telephone network, a private telephone network, or 
some other network -for purposes of transmitting and 
receiving telecommunications, including video commu- 
nications. The video workstation further includes a gen- 
eral-purpose processor 135, and a memory 137 that 
stores programs for execution and data for use by proc- 
essor 135. A local area network (LAN) interface 134 
connects at least some video workstations 103-104 to 
a LAN 100, or alternatively to a wide area network 
(WAN). Video workstations 103-104 can communicate 
with each other over LAN 100, including placing video 
calls to each other over LAN 100. LAN 100 illustratively 
implements the terminal control protocol/internet proto- 
col (TCP/IP). 

The system of FIG. 1 further includes a multi-media 
messaging system 101. Messaging system 101 is illus- 
tratively either the AT&T Intuity® system or the AT&T 
Definity® Audix® system. These systems structure a 
multi-media message 700 in the manner shown in FIG. 
2. Message 700 has a message header component 701 
that comprises a plurality of header elements 702. Each 
element 702 provides some information about the mes- 
sage, such as who it is for, who it is from, whether it is 
a private or a priority message, and what message-body 
components it contains. Message 700 further has a 
message body 703 that contains one or more message- 
body components 704 each expressed in a different me- 



dium. Supported media include voice, text, fax, binary 
data, and video. The video component of the message 
can contain moving pictures, moving pictures with syn- 
chronized audio, shared whiteboard, shared applica- 
5 tions, or any other communications that include moving 
images. Message-body components 704 are usually 
separate files that are linked to message header com- 
ponent 701 by pointers. 

Returning to FIG. 1. messaging system 101 in- 
10 eludes a mass memory 111 that implements a plurality 
of message mailboxes 120-121 for messaging service 
subscribers, at least some of whom are also users/own- 
ers of video workstations 103-104. Messaging system 
101 further includes a processor 112, and a memory 113 
'5 that stores programs for execution and data for use by 
processor 112. A plurality of DSP-based voice and 
Touch-Tone ports 114-115 couple system 101 to a plu- 
rality of telephone lines 1 64-1 65 by means of which call- 
ers and subscribers can access messaging system 101 
^0 in the conventional manner A LAN interface 110 con- 
nects messaging system 101 to LAN 100. 

The system of FIG. 1 also preferably includes an 
adjunct mass store 102. Mass store 102 is illustratively 
a disk-storage system controlled by the UNIX® operat- 
2S ing system. It functions as an adjunct to messaging sys- 
tem 101 to extend the capacity of mass memory ill. 
Conventional network file system (NFS) connectivity be- 
tween messaging system 101 and mass store 102 turns 
mass memory 122 into an extension of mass memory 
^0 111. Mass store 102 includes a mass memory 122, a 
processor 123, a memory 124 that stores programs for 
execution and data for use by processor 1 23, and a LAN 
interface 1 25 that connects mass store 1 02 to LAN 1 00. 
The software of messaging system 101 includes a 
35 voice session controller (VSC) 118 that implements a 
conventional Touch-Tone user interface to messaging 
system 101 over telephone lines 164-165. The software 
also includes an application database (ADATA) 117. 
which is a database mechanism that implements a mes- 
•^0 saging database, including mailboxes 120 and 121. 
ADATA 117 includes video as one of its defined mes- 
sage media objects, along with audio, fax, binary data, 
and any other media objects that are defined for mes- 
saging system 101 . The software of messaging system 
^5 101 further includes an application interaction server 
(AIS) 116, which functions as a TCP/IP remote proce- 
dure call (RPC) server for communications over LAN 
100 to and from messaging system 101 . 

The software of adjunct mass store 102 includes a 
50 video file transfer process ( VFT) 1 26. VFT 1 26 commu- 
nicates with AIS program 116 over LAN 100 and re- 
sponds to its requests to either accept video files from 
messaging system 1 01 for storage in mass memory 1 22 
or retrieve stored video files from mass memory 1 22 for 
55 return to messaging system 101 . 

The software of video workstations 103-104 in- 
cludes a multi-media messaging application program in- 
terface (MMAPI) 140, which implements communica- 
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lions between the video workstations and AIS 116 of 
nnessaging system 101. Comnnunications between 
MI\/AP! 140 and messaging system 101 are implement- 
ed as TCP/IP RPCs using the conventional client/server 
request/response model of interaction. MMAPI 140 in- 
cludes video file transfer among its file transfer capabil- 
ities, along with audio file transfer, binary data file trans- 
fer, and file transfer capability of any other desired me- 
dia. If messaging system 1 01 is the Intuity system or the 
Definity Audix system, MMAPI 140 is preferably a ver- 
sion of the AT&T Intuity MAPI (IMAPI) or AT&T Audix 
MAPI (AMAPI). The IMAPI or AMAPI is a TCP/IP RPC 
implementation which supports access to the Intuity or 
Audix system from client application processes that are 
interconnected with the Intuity or Audix system by a LAN 
or a WAN. The IMAPI or AMAPI interface is specified as 
a set of C-language function calls, either in a standard 
UNIX system archive or library on UNIX® operating sys- 
tem client machines, or in a Dynamic Link Library (DLL) 
on Windows® or OS/2® operating system client ma- 
chines. 

The software of video workstations 103- 104 also in- 
cludes a message manager (MM) 141 that implements 
a graphical user interface (GUI ) for a user of video work- 
station 132 to messaging system 101. Like ADATA 117 
of messaging system 101, MM 141 includes video as 
one of its defined message media objects. If messaging 
system 101 is the Intuity system or the Definity Audix 
system, MM 141 is preferably a version of the AT&T In- 
tuity Message Manager application. 
FIGS. 11-13 illustrate the interface that the Intuity Mes- 
sage Manager presents to the user. FIG 11 shows mes- 
sage retrieval. FIG. 12 shows message playback. And 
FIG. 13 shows mail-message creation. 

The software of video workstations 103-104 further 
includes a video call answer agent (VCAA) 143 which 
interacts with ISDN port 136 to answer video calls in- 
coming over the respective one of ISDN lines 153-154 
that are not answered by the users of video workstations 
103-104. VCAA 143 implements in software an answer- 
ing machine for video calls at workstations 103-104. 

Finally, the software of video workstations 103-104 
includes a video control application program interface 
(VCAPI) 142. VCAPI 142 implements the ability to 
record video from camera 132 or ISDN line 153 into a 
file in memory 1 37 and to play video from a file in mem- 
ory 1 37 on display 1 30 or ISDN line 1 53. VCAPI 1 42 is 
illustratively either the Lotus ScreenCam multimedia 
screen and sound capture utility or the AT&T Vislium 
software developer kit, or the Insoft Communique! de- 
veloper's toolkit. 

Configured as described above, the telecommuni- 
cations system of FIG. 1 enables messaging system 
1 0 1 to provide video messaging services for video work- 
stations 103-104. Specifically it enables messaging 
system 101 to support the call scenarios of FIGS. 3-5. 
FIG. 3 shows an illustrative call-answer scenario. A vid- 
eo call from video workstation 104 comes to video work- 
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station 103 over ISDN line 153 or LAN 100. and the call 
either gets a busy indication or is not answered by the 
user of workstation 103 within a predetermined time. 
Workstation 103 provides call coverage for the user. It 

5 answers the call, records a video message, and sends 
the recorded message to MMMS 101 for storage in the 
user's mailbox. FIG. 4 shows an illustrative message- 
retrieval scenario. When a video message is stored in 
the mailbox of the user of workstation 103 in MMMS 101 , 

10 the user can use workstation 103 to access MMMS 101 
via LAN 100, retrieve the message, and view it on work- 
station 103. Or. the user can access MMMS 101 by tel- 
ephone over a telephone line 169 and retrieve the video 
message's header and non-video components. FIG. 5 

IS shows an illustrative mail-message scenario. The user 
of workstation 1 03 can create a video message on work- 
station 103 and then transfer it via LAN 100 to MMMS 
101 and cause MMMS 101 to store copies of the mes- 
sage in one or more mailboxes. 

20 The call-answer scenario is effected in the manner 
shown in FIG. 6 and described below. References below 
to software performing certain functions will be under- 
stood to mean a processor performing those functions 
in response to executing the named software. 

2S When a call incoming either on LAN 1 00 or on ISDN 
line 153 is answered, it is handled in the conventional 
manner by application software of video workstation 
1 03. However, when the call is not answered by the user 
of video workstation 103 within a predetermined period 

00 of time, execution of VCAA 143 is invoked, at step 300. 
VCAA 143 invokes MMAPI 140 to access messaging 
system 101 and interact through AIS 116 with ADATA 
1 1 7 to cause ADATA 1 1 7 to return the personal greeting 
that is stored in mailbox 1 20 of the user of video work- 

35 station 1 03, at step 302. MMAPI 1 40 stores the returned 
personal greeting in a temporary file in memory 137, at 
step 304. VCAA 1 43 then answers the call on ISDN line 
15.3 or LAN 100, at step 306. VCAA 143 invokes VCAPI 

142 to play out the personal greeting from the temporary 
40 file onto ISDN line 1 53 through ISDN port 1 36 or onto 

LAN 100 through LAN interface 1 34. at step 308. VCAA 

143 then watts for the caller to either hang up the call or 
to record a message, at step 31 0. If the caller hangs up, 
execution of VCAA 143 ends, at step 312. If the user 

4S chooses to record a message, VCAA 143 stores infor- 
mation about the call, such as date, time, and caller 
identification, at step 314, and invokes VCAPI 142 to 
record and store the message in a temporary file in 
memory 137, at step 316. When the caller completes 

so recording and hangs up, VCAPI 1 42 reports additional 
information about the message, such as its length and 
what media components it includes, to VCAA 143, at 
step 318. VCAA 143 again invokes MMAPI 140 to ac- 
cess messaging system 101 and interact through AIS 

55 116 with ADATA 1 1 7 to create a header for the message 
in mailbox 1 20 from the information stored about the call 
and message by VCAA 1 43 at step 320. VCAA 1 43 fur- 
ther causes MMAPI 1 40 to interact through AIS 1 1 6 with 
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ADATA 1 1 7 to transfer the message from the temporary 
. file in memory 137 into mailbox 120, at step 322. Exe- 
cution of VCAA 143 then ends, at step 324. 

If MMAPI 140 is the Audix MAPI or Intuity MAPI, a 
file transfer from video workstation 103 to messaging 
system 101 is normally accomplished using the AKAAP\ 
or IMAPI "Put' command, which effects the transfer in 
individual 8-kilobyte chunks over LAN 100. Since video 
files tend to be large, their transfer can take many indi- 
vidual 8-kilobyte transfers and adversely affect the per- 
formance of AIS 116. To alleviate this problem, the 
AMAPI or IMAPI is enhanced to provide a "Put large- 
command for transferring large files. 

The "Put large' command is diagrammed in FIG. 7. 
It relies upon the standard socket (logical port) mecha- 
nism of the TCP/IP UDP datagram protocol. When 
MMAPI 1 40 issues the "Put large" command for the first 
time, at step 400, the UDP mechanism creates a socket 
for video workstation 103 on LAN 100, at step 402. This 
socket is then reused for all subsequent 'large" com- 
mands issued by MMAPI 140. The command issued at 
step 400 includes the socket's address, and a message 
1 D of the video file. Al S 1 1 6 receives the "Put large" com- 
mand, at step 404, and in response validates the re- 
quest and gets a filename that corresponds to the re- 
ceived message ID from ADATA 117, at step 405. AIS 
116 then creates a record in shared memory (a portion 
of memory 1 1 3 that is accessible to, and hence is shared 
with, processor 123 of mass store 102), at step 406, in 
which it stores the address of the socket of workstation 
1 03 and the filename of a file in mass memory 1 22 which 
it obtained from ADATA 117, at step 408. AIS 116 then 
sends an acknowledgment of the "Put large" command 
to MMAPI 140, at step 410, that conveys to MMAPI 140 
the record index of the record created at step 406. 
MMAPI 140 receives the acknowledgement, at step 
412, and in response, it makes a standard TCP/IP Inte- 
met service request containing the record index at the 
socket of workstation 103 on LAN 100. at step 414. The 
request is received by the standard RPC "Bind" process 
of the UNIX operating system of mass store 102. at step 
416. If this is the first time that such a request has been 
received, the RPC mechanism creates a socket for 
mass store adjunct 102 on LAN 100, at step 417. This 
socket is then reused for all subsequent requests. In re- 
sponse to receipt of the request, processor 123 creates 
("spawns") a copy of VFT 126 to sen/e the request, at 
step 418. 

The copy of VFT 126 uses the record index to ac- 
cess the record in the shared memory portion of memory 
113 and retrieves from the record the address of the 
workstation 103 socket and the filename, at step 420. 
The copy of VFT 126 then interacts with MMAPI 140 
through the sockets of video workstation 1 03 and mass 
store adjunct 102 in a sequence of repeated reads, 
writes, and acknowledgments of data, using standard 
TCP/IP UDP datagrams, until an end-of-file is encoun- 
tered, to effect the file transfer between workstation 1 03 



and mass store adjunct 102. and stores the file in mass 
memory 122 under the filename designated by AIS 116 
in the retrieved record, at steps 422 and 424. When the 
file transfer is completed, the copy of VFT 126 that was 
s created to accomplish this transfer is destroyed, at step 
426. 

With the "Put large" command available to it, 
MMAPI 140 uses the "Put" command to transfer the 
message header information and the non-video portions 
10 of the message to messaging system 1 01 . at steps 320 
and 322 of FIG. 6. and uses the 'Put large" command 
to transfer the video portion of the message to MMMS 
101 or mass store 102, at step 322 of FIG. 6. 

Once the message is stored either in its entirety in 
'5 messaging system 101 , or partly in messaging system 
101 and partly in mass store 102, the subscriber/owner 
of mailbox 120 has conventional access to all parts of 
the message, except forthe video object, via telephone 
lines 1 64 and any instrumentalities (e.g. telephones, ter- 
20 minals) associated therewith. To gain access to the vid- 
eo object of the message, the subscriber must use video 
workstation 103. The subscriber can also access the en- 
tire message through video workstation 103. 

To obtain access to his or her mailbox 1 20 at video 
25 workstation 103. the subscriber/owner of mailbox 120 
invokes execution of MM 1 41 , at step 500 of FIG. 8. MM 
141 responds by presenting a user menu to the sub- 
scriber on the display screen of video workstation 103, 
at step 502. The subscriber makes a selection from the 
30 menu and MM 141 receives it, at step 504, and checks 
whether it is a request to terminate execution of MM 1 41 , 
at step 506. If so, MM 141 proceeds to step 528 to ter- 
minate; if not, MM 141 checks whether the request is to 
display message headers waiting for retrieval in the sub- 
35 scriber's mailbox or some other request, at step 508. If 
it is some other request, MM 141 undertakes to perform 
the selected action in a conventional manner, at step 
510. and then returns to step 502. If the request is a 
request to display message headers. MM 141 invokes 
40 MMAPI 1 40 to access messaging system 101 and inter- 
act through AIS 116 with ADATA 117 to cause ADATA 
11 7 to return the headers of messages stored in mailbox 
120. at step 512 MM 141 then presents the headers to 
the user via display 130, at step 514. If the user decides 
to retrieve one of the messages 1 20 and so indicates to 
MM 141, at step 5 16, MM 141 responds by again invok- 
ing MMAPI 140 to access messaging system 101 and 
interacting through AIS 116 with ADATA 117 to retrieve 
the message body components from mailbox 120, at 
50 step 518, and stores them in a temporary file in memory 
137, at step 520. If the message includes a video com- 
ponent. MM 141 invokes VCAPI 137 to present (play) 
the video component to the user through display 130 
and speakers 1 31 , at step 522. If the user decides to act 
55 upon the message in some way, such as to forward it to 
another user's mailbox 121 or to delete it from mailbox 
120, the user informs MM 141. at step 524, and MM 141 
responds by invoking MMAPI 140 to interact through 
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AIS 116 with ADATA 117 to cause ADATA 117 to under- 
take the desired action, at step 526. MM 141 then re- 
turns to step 502. 

If MMAPI 140 is the Audix MAPI or Intuity MAPI, a 
file transfer fronn nnessaging system 101 is nornnally ac- s 
connplished using the AMAPI or IMAPI "Get' command 
which, like the above-described "Put" command, effects 
the transfer in individual 8-kilobyte chunks, with the 
same deleterious affect on the performance of AIS 1 1 6. 
To alleviate this problem, the AMAPI or IMAPI is en- w 
hanced to provide a "Get large" command for transfer- 
ring large files. Except for the direction of file transfer, 
the "Get large" command works the same way as the 
"Put large" command, and hence is also diagrammed in 
FIG. 7 and described by the accompanying description. '5 

The user of workstation 103 can also create a mail 
message in his or her mailbox 120 and then send it to 
a mailbox 121 of another user. To do so, the user of 
workstation 103 invokes MM 141, at step 600 of FIG. 9, 
and selects message creation, at step 604, from the us- 20 
er menu presented by MM 1 41 at step 602. In response, 
MM 141 invokes VCAPI 142 to record the user's mes- 
sage, using camera 132 and microphone 133, into a 
temporary file in memory 137, at step 606, When the 
recording is completed, VCAPI 142 gives information 25 
about the message, such as its length and what media 
objects it contains, to MM 141, at step 608, and exits. 
MM 141 now invokes MMAPI 140 to access messaging 
system 101 and interact through AIS 116 with ADATA 
1 1 7 to transfer the message from the temporary file in 30 
memory 137 into mailbox 120, at step 610. If the mes- 
sage has a video object, "Put large" is used to accom- 
plish the transfer in the manner described previously. 
MM 141 also uses MMAPI 140 to interact through AIS 
1 16 with ADATA 117 tocreateaheaderfor the message, 3S 
step 612, to invoke any desired features for the mes- 
sage (e.g., "make private" or "priority"), at step 614, and 
to address the message and schedule it for delivery, at 
step 616. The user may, then terminate MM 141 at the 
user's option, at step 61 8. ^0 

A drawback of the implementation illustrated in FIG. 
1 is that it does not readily allow for a caller who has 
reached either a powered-down or a busy video work- 
station 103-104, or who has called a video workstation 
that is disconnected from the system of FIG. 1 . A way ^5 
to implement this capability is to designate at least one 
of the workstations 1 03-1 04 to act as a messaging sen/- 
er (essentially an answering machine) on behalf of other 
workstations in the system of FIG. 1 , and to redirect to 
it all calls that go unanswered at the destination work- so 
stations 103-104 for longer tfian a predetermined 
amount of time. In the case of calls incoming on ISDN 
lines 153-154, such redirection may be accomplished 
by a switching system with video-Call redirection capa- 
bility -such as an AT&T 5ESS(g) switching system- that ss 
is a part of network 170. In the case of calls incoming 
on LAN 100, such redirection may be accomplished by 
the sen/er workstation itself monitoring all call-origina- 
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tion traffic on LAN 100 and taking on itself the identity, 
with respect to LAN 100, of any non-answering worksta- 
tion. 

Instead of using a plurality of video workstations as 
servers, an alternative embodiment is shown in FIG. 10. 
Here, a video call server 200 is added to the system of 
FIG. 1 . (Elements in FIG. 10 that are the same as in FIG, 
1 retain the same numerical designations as in FIG. 1 ). 
Video call server 200 is a stored-program-controlled 
machine that includes a processor 205 for executing 
programs, a memory 203 that stores programs for exe- 
cution and data for use by processor 205. and a mass 
memory 204 for storing video messages. Mass memory 
204 serves the function of adjunct mass store 102 ol 
FIG. 1 , and hence adjunct mass store 1 02 is not needed 
in the system of FIG. 6. Video call server 200 includes 
database manager (DBM) 208 software that imple- 
ments NFS connectivity between messaging system 
101 and mass memory 204 to turn mass memory 204 
into an extension of mass memory 111. Illustratively 
DBM 208 need involve no more than the conventional 
database management functions of the UNIX operating 
system kernel (i.e., the basic UNIX file system ready 
write/directory access functionality). Video call server 
200 includes a plurality of ISDN ports 201-202, each one 
of which is an equivalent of I SDN port 1 36 of video work- 
station 103. ISDN ports 201-202 are connected by re- 
spective ISDN lines 211-212 to network 170 that in- 
cludes a switching system with video call-redirection ca- 
pability. Video call server 200 is connected to LAN 100 
by a LAN interface 206 that is an equivalent of LAN in- 
terface 110 of messaging system 1 01 . For communicat- 
ing with messaging system 101, video call server in- 
cludes MMAPI 207 that is an equivalent of MMAPI 140. 

Video call server 200 answers all calls that are not 
answered at workstations 103-104 within a predeter- 
mined period of time. Hence, workstations 103-104 no 
longer need VCAA 103. For this purpose, video call 
server 200 includes a video session controller (VSC) 
209. Functionally VSC 209 is equivalent to multiple cop- 
ies of VCAA 1 43 and VCAP1 1 42, whereby multiple ports 
201-202 may be served at the same time. 

Of course, various changes, modifications, and ex- 
tensions to the illustrative emlxxJiment described above 
will be apparent to those skilled in the art. For example, 
network 1 70 may be an ATM network instead of an I SDN 
network. Such changes and modifications can be made 
without departing from the spirit and the scope of the 
invention and without diminishing its attendant advan- 
tages. It is therefore intended that such changes and 
modifications be covered by the following claims. 



Claims 

1. A video messaging system (FIG. 1 ) comprising: 
a video communications network (100); 
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one or more video communications terminals 
(103-104) connected to the video communica- 
tions network: 

at least one telephone line (164-165); 
a multi-media message sen/er ( 1 0l - 1 02) con- s 
nected to the telephone line for storing messag- 
es having a plurality of message portions at 
least some of which message portions may be 
represented in any one of a plurality of different 
media, CHARACTERISED BY the multi-media io 
message server including 
first interface means (114-115. 117-113) con- 
nected to the at least one telephone line for pro- 3. 
viding access over the at least one telephone 
line to at least some portions of the messages is 
stored in the multi-media message server, and 
second interface means (110, 116-117) con- 
nected to the video communications network 
for receiving via the video communications net- 
work video messages having portions repre- 20 
sented in a video medium and storing the re- 4. 
ceived video messages in the multi-media mes- 
sage server, and for retrieving the stored video 
messages and transmitting the retrieved video 
messages via the video communications net- 2S 
work; 

at least a first one of the video communications 
terminals including 

third means (134, 136-137, 140, 142-143) re- 
sponsive to a video communication incoming to 30 
the at least first one of the video communica- 
tions terminals and not answered by a recipient 
of the video communication, for answering the 
incoming video communication and recording 
from the video communication a video mes- 35 
sage having a portion represented in the video 
medium, and 

fourth means (134, 140) responsive to the third 
means recording the video message, for trans- 
mitting the recorded video message via the vid- 40 5. 
eo communications network to the multi-media 
message server, and causing the second inter- 
face means to receive and store the transmitted 
video message in the message server; and at 
least a second one of the video communica- **5 
tions terminals including 
fifth means (130, 134, 138, 140-142) for caus- 
ing the second interface means to retrieve and 
transmit the stored video inessage, and receiv- 
ing the video message transmitted from the so 
multi-media message server via the video com- 6. 
munications network for presentation of the re- 
ceived video message to a user of the at least 
second one of the video communications ter- 
minals. 55 

2, The video messaging system of claim 1 further com- 
prising: 



at least one video communications line 
(153-154) independent of the video communi- 
cations network and connected to at least the 
first one of the video communications termi- 
nals; wherein 

the third means are responsive to the video 
communication incoming to the at least first one 
video communications terminal on the at least 
one video communications line, and answer the 
incoming video communication on the at least 
one video communications line. 

The video messaging system of claim 1 wherein: 

the third means are responsive to the video 
communication incoming to the at least first one vid- 
eo communication terminal on the video communi- 
cations network, and answer the incoming video 
communication on the at least one video communi- 
cations network. 

The video messaging system of claim 1 wherein: 

the multi-media message server comprises 
first mass memory means (111) for storing 
some of the portions of the messages that are 
stored by the multi-media message server, con- 
nected to the first and the second interface 
means without intermediacy of the video com- 
munications network, and 
second mass memory means (122) serving as 
an extension of the first memory means for stor- 
ing others of the portions of at least some of the 
messages that are stored by the multi-media 
message server, the second mass memory 
means being connected to the first mass mem- 
ory means and to the first and the second inter- 
face means via the video communications net- 
work. 

The video messaging system of claim 4 wherein: 

the first mass memory means store the portions 
of the messages that are stored by the multi- 
media message server other than the portions 
represented in the video medium, and 
the second mass memory means store those 
portions of the messages that are stored by the 
multi-media message server that are repre- 
sented in the video medium. 

The video messaging system of claim 5 wherein: 

the fourth means communicate the portions 
of the messages that are stored by the first mass 
memory means of the multi-media message server 
to or from the second interface means, and commu- 
nicate the portions of the messages that are stored 
by the second mass memory means of the multi- 
media message server to or from the second mass 
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memory means without intermediacy of the second 
interface means. 

7. The video messaging system of claim 1 wherein; 

5 

the third means include 
a memory (137): 

means (143) responsive to the incoming video 
communication for answering the video com- 
munication; 10 
means (142) responsive to the answering, for 
recording the video message from the an- 
swered video communication into a file in the 
memory; and 

the fourth means include means (140) respon- is 
sive to the recording, for transferring the file 
from the memory via the video communications 
network to the multi-media message server. 

8. The video messaging system of claim 7 wherein: 20 

the fifth means include 
a display screen (130); 
a memory (137): 

means (134, 140) responsive to a user request, 2S 
for transferring a file containing the video mes- 
sage from the multi-media message server and 
storing il in a file in the memory; and 
means (138, 141-142) for playing the video 
message from the file on the display screen. oo 

9. A video message server (101) for use with at least 
one telephone line (164-165). a video communica- 
tions network ( 1 00), and one or more video commu- 
nications terminals (103-1 04) connected to the vid- 35 
eo communications network, at least a first one of 
which video communications terminals generates 
messages each having a plurality of message por- 
tions at least one of which message portions is rep- 
resented in a video medium, and transmits the mes- 
sages on the video communications network, and 

at least a second one of which video communica- 
tions terminals receives video messages from the 
video communications network for presentation to 
users, the video message server CHARACTER- -^5 
ISED BY 

means ( 1 1 1 ) for storing messages each having 
a plurality of message portions at least one of 
which message portions may be represented so 
in any one of a plurality of different media in- 
cluding the video medium; 
first interface means (114-115, 117-118) for 
connecting the video message server to the at 
least one telephone line to provide access over ss 
the at least one telephone line to at least some 
portions other than portions represented in the 
video medium of the messages stored in the 
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storing means: and 

second interface means (110, 116-11 7) for con- 
necting the video message server to the video 
communications network, responsive to receipt 
via the video communications network from the 
first video communications terminal of a video 
message generated by the first video commu- 
nications terminal from a video communication 
not answered by an intended recipient of the 
video communication and received and an- 
swered by the first video communications ter- 
minal, for storing the received video message 
in the storing means, and further responsive to 
receipt of a request from the second video com- 
munications terminal, for retrieving a stored 
video message from the storing means and 
transmitting the retrieved message to the sec- 
ond video communications terminal over the 
video communications network for presenta- 
tion of the retrieved message by the second vid- 
eo communications terminal to a user. 

1 0. A video commun ications terminal ( 1 03) for use with 
a video communications network (100), at least one 
telephone line (164-165), and a multi-media mes- 
sage server (101) for storing messages having a 
plurality of message portions at least some of which 
message portions may be represented in any one 
of a plurality of different media, the multi-media 
message server including a first interface (114-115, 
117-118) connected to the at least one telephone 
line for providing access over the at least one tele- 
phone line to at least some portions of the messag- 
es stored in the multi-media message server, and a 
second interface (110, 116-117) connected to the 
video communications network for receiving via the 
video communications network video messages 
having portions represented in a video medium and 
storing the received video messages in the multi- 
media message server, and for retrieving the stored 
video messages and transmitting the retrieved vid- 
eo messages via the video communications net- 
work, the video communications terminal CHAR- 
ACTERISED BY 

first means (134, 136-137, 140, 142-143) re- 
sponsive to a video communication incoming to 
the video communications terminal and not an- 
swered by a recipient of the video communica- 
tion, for answering the incoming video commu- 
nication and recording from the video commu- 
nication a video message having a portion rep- 
resented in the video medium; 
second means (1 34, 1 40) for connecting to the 
video communications network and responsive 
to the first means recording the video message, 
for transmitting the recorded video message via 
the video communications network to the multl- 
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media message server and causing the second 
interlace to receive and store the transmitted 
video message in the message sen/er such that 
access to at least some portions other than the 
portions represented in the video medium of the s 
video message stored in the message server is 
provided over the at least one telephone line 
through the first interface; 
third means (130, 134, 140-141) responsive to 
a request received from a user of the video w 
communications terminal, for causing the sec- 
ond interface to retrieve and transmit the stored 
video message on the video communications 
network, and receiving the video message 
transmitted from the multi-media message is 
server via the video communications network; 
and 

fourth means (138, 130, 141-142) responsive 
to the receipt of the video message by the third 
means for playing the received video message 20 
to the user of the video communications termi- 
nal. 



25 



30 



35 



40 



45 



SO 



56 



10 

BNSOOCID: <EP ^0762763A2J_> 




BNSOOCID: <EP ^0762763A2J^ 



11 



EP 0 762 763 A2 



FIG. 2 



700 



702 



702 



704 



>701 



>703 



FIG, 3 



104 


(CALL) . 


153/100 



103 



BUSY/NO ANSWER 



100. 



(CALL COVERAGE) 



101 



FIG. 4 





100 


103 


: 
■ 



101 



164 



BNSOOCID: <EP_07a27e3A2J_> 



12 



EP 0 762 763 A2 



FIG. 5 



100 



103 



101 



FIG, 6 



302^ 
304^ 
306 



r$TARn .300 



OBTAIN PERSQHAL GREETING FROM MAILBOX 



STORE OBTAINED PERSONAL GREEHNG IN TEMP. RLE 



I 



ANSWER CALL 



PLAY OUT PERSONAL GRCTNG FROM TEMP.Tf iT 

310 



I 



HANGUP ? 



314^ 
316^ 

318^ 
320^ 
322 



NO 



STORE INFORMATION ABOUT CAU. 



I 



RECORD MESSAGE IN TEMP. RLE 

t : 



asp 

^312 



STORE INFORMATION ABOUT MESSAGE 
I 



CREATE MESSAGE HEADER IN MAILBOX 



I 



TRANSFER MESSAGE FROM TEMP. RLE INTO MAILBOX 
rENirV -324 



BNSDOCtO: <EP 0762763A2 I > 



13 



EP 0 762 763 A2 



FIG. 7 



140 



116 



126 



r ISSUE "lAfiCr \ 
V COMMAND / 



7 



RECEIVE 'LARCr 
COMMAND 



400 
402^ 



CREATE 
SOCKET 
FOR 
WORK- 
STATION 



I 



VAUDATE COMMAND 
AND GET COfKESPONOWG 
niENAME 

I 



.*12 



CREATE RECORD IN 
SHARED MEMORY 



STORE miNAtff 
IN RECORD 



RECEIVE 




ACKNOWLEDGE 'LARGT 


ACKNOWLEDGMENT 




COMMAND 



-404 



•405 



-406 



-408 



•410 



ISSUE nil 

TRANSFER REQUEST 
AT SOCKET 



416 



TRANSFER 
REQUEST 



414 




r418 



SPAWN VFT 
COPY TO 
SERVE 
REQUEST 



422 



EFFECT RLE 
TRANSFER 



/READ/SEND UQP DATAGRAM/ACK. /WRITE SEQUFNCF^ 



424^- 



r420 
RETRIEVE 
RECORD 
FROM SHARED 
MEMORY 

I 

EFFECT FILE 
TRANSFER TO/ 
FROM HLENAME 

^ r' 

426 



BNSOOCIO: <EP ^e»762763A2J^ 



14 



EP 0 762 763 A2 



FIG. 8 



PRESENT yCHU TO USER 



502 



RECEIVE SEliCnON 



( 



i f506 



504 




SELECTION IS TO 
TERMINAL ? 
♦NO 



SELECTION IS TO DISPLAY 
MESSAGE HEADERS ? 



riNir> -528 

508 



OBTAIN MESSAGE HEADERS 
FROM MAILBOX 

E 



PRESENT HEADERS 
TO USER 
I 



RECEIVE MESSAGE 
RETRIEVAL SELECTION 



OBTAIN SELECTED MESSAGE 
TROM MAILBOX 

I 



STORE OBTAINED MESSAGE 
IN TEMP. niE 



i 



PRESENT OBTAINED MESSAGE 
FROM TEMP, m TO USER 
I 



RECEIVE MESSAGE 
ACnON SELECTION 



I 



512 



514 



516 



518 



520 



522 



524 



UNDERTAKE SELECTED ACTION k 526 



BNSDOCID: <EP ^0762763A2J^ 



15 



EP 0 762 763 A2 



FIG. 9 



rsTARTV -eoo 



PRESENT MENU TO US ER 
I 



RECEIVE yESSAGE CREA TION SEIiCnON 
I 



RECORD NEW MESSAGE IN TEMP, nil 



STORE IMFORMAHON ABOUT MESSAGE 
I 



TRANSFER MESSAGE FROM TEMP. ni£ 
INTO MLBOX 



FORM MESSAGE HEADER IN MAILBOX 



INVOKE FEATURES FOR ME SSAGE 
I 



-602 
■604 
■606 
-608 

•610 

■612 
■614 



SCHEDUII MESSAGE DELIVERY TO ADbRESSEEb -616 



205 



^00 



204 .203 



FIG, 10 



.201 



PROCESSOR 


MASS 
MEMORY 


MEMORY ^209 ^ 


ISDN 
PORT 


♦<BaD— ( vsc f 
2oT{ \ 


ISDM 
PORT 


\m INTERFACE 



206' 



LAN 100 

_\ 



T 
202 



105 



VIDEO 
WORKSTATION! 




MMMS 



101 



BNSDCXJID: <EP ^0762763A2J_> 



16 




BEST AVAILABLE COPY 



BNSDOCID: <EP ^07627e3A2_l_> 



17 




BNSOOCID: <EP_0762763A2_I_> 



18 




5 BEST AVAILABLE W 



BNSDCXID: <EP_0762763A2J_> 



19 



THIS PAGE BLANK (uspto) 



